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Telnet 3270 Regime Option 


STATUS OF THIS MEMO 


This RFC specifies a proposed standard for the Internet community. 
Hosts on the Internet, that want to support 3270 data stream within 
the Telnet protocol, are expected to adopt and implement this 
standard. Distribution of this memo is unlimited. 


1. Command Name and Code 
3270-REGIME 29 
2. Command Meaning 


IAC WILL 3270-REGIME 


Sender is willing to send list of supported 3270 Regimes in 
a subsequent sub-negotiation. 


IAC WON’ T 3270-REGIME 
Sender refuses to send the list of supported 3270 Regimes. 
IAC DO 3270-REGIME 


Sender is willing to receive a list of supported 3270 Regimes in a 
subsequent sub-negotiation. 


IAC DON’T 3270-REGIME 
Sender refuses to accept the list of supported 3270 Regimes. 


TAC SB 3270-REGIME ARE REGIME-LIST IAC SE 


Sender sends the list of all possible 3270 Regimes it is able to 
support. The code for ARE is 1. 


REGIME-LIST is an ASCII string which has meaning to both sides of 
the negotiation. This string may be composed of different 
terminal type names (as specified in the "Assigned Numbers") which 
are separated by space character. Terminal type names which have 
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imbedded spaces should escape it with backslash character (’\’). 
Backslash character imbedded into terminal type name should be 
escaped with another backslash character. 


Empty REGIME-LIST means, that sender is able to support only NVT 
ASCII terminal as defined in [4]. 


TAC SB 3270-REGIME IS REGIME IAC SE 


Sender is stating the name of the terminal it is willing to 
support. The code for IS is 0. 


REGIME is an ASCII string (possibly empty) which is substring of 
the received REGIME-LIST string. Empty string means that the 


sender is willing to support only NVT ASCII terminal as defined in 


[4]. 
Default 
WON’ T 3270-REGIME 
3270 Regime will not be established. 
DON’T 3270-REGIME 
3270 Regime will not be established. 
Motivation for the option 


This option allows a telnet server running VM or MVS to negotiate 


with the telnet client on the type of data stream (3270 or NVT ASCII) 


which both sides are willing support. 


The main reason for this option is to allow simple and efficient way 
to: 


o state, that both client and server want to exchange 3270 data 
stream, 


o switch from 3270 Regime into NVT ASCII Regime and back into 3270 


Regime, 


o dynamically renegotiate 3270 Regime parameters (like terminal 
type). 
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Support for 3270 data stream requires that both sides: 
o be able to exchange binary data, 


o be able to put well defined delimiters into inbound/outbound 
data stream, 


o be able to establish the agreement between client and server on 
what type of terminal will be used. 


Current implementations requires 3 different options, TERMINALTYPE 
[1], BINARY [2] and EOR [3], to be successfully negotiated between 
client and server prior to establishing 3270 Regime. Moreover, it is 
unclear at what point in this negotiation process, 3270 regime is 
actually established (whether after TERMINALTYPE or after BINARY or 
after EOR). Also, order for these negotiations was never specified. 


Subnegotiation for the TERMINALTYPE is possible with only single 
terminal type at a time. 


Once 3270 Regime is established, there is no standard of how to get 
out of this regime back into NVT ASCII mode. 


Based on the 3270 Regime requirements, which stated above, we feel 
that separate negotiation for EOR and BINARY should not be done. 
Rather, 3270 Regime establishment should imply that: 


o each character in the Telnet data stream should be interpreted 
as 8 bits of binary data, 


o both sides agreed to use a certain character sequence (Telnet IAC 
EOR) as a delimiter in inbound/outbound Telnet data stream, 


o both sides agreed on the type of the terminal they are willing 
to support. 


By providing the list of possible terminals which Telnet client can 
support, telnet server could select the type of the terminal it can 
support and pass it back to the Telnet client, thus eliminating 
multiple TERMINALTYPE negotiations. 


As stated in [5], "The purpose of the Telnet Protocol is to provide a 
fairly general, bi-directional, eight-bit byte oriented communication 
facility." Therefore we feel that such issues as color support, 
graphics support, extended data streams mapping, etc., do not belong 
logically to the Telnet protocol, but rather should be considered as 
a part of a separate protocol which defines 3270 inbound/outbound 
data stream (see [5], [6], [7], [8]). The purpose of this memo is 
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not to describe (or define) protocols which are used in 3270 Regime, 
but rather define a new option for the Telnet Protocol, which would 
allow both sides to negotiate for the 3270 Regime establishment over 
the telnet connection. 


While this options does not include direct negotiation for such 
things as colors, graphics, structured fields, etc., certain features 
(like the ability to support colors) may be negotiated indirectly by 
using certain terminal type names specified in 3270-REGIME 
subnegotiation. 


We also feel that such issues as keyboard mapping, whether to have 
one telnet for both ASCII and 3270 mode or two separate programs, one 
for ASCII and another for 3270 mode, are implementation dependent and 
should be considered as a local matter. 


5. Description of the Option 


WILL and DO commands are used to obtain and grant permission for the 
subsequent subnegotiation. Both sides must exchange WILL 3270-REGIME 
and DO 3270-REGIME prior to subnegotiation. The actual exchange of 
information is done within the option subcommand (IAC SB 
3270-REGIME) . 


Either Telnet client or Telnet server can initialize 3270-REGIME 
negotiation. However, in order to simplify negotiation, only Telnet 


client is allowed to send IAC SB 3270-REGIME ARE... IAC SE command, 
and only Telnet server is allowed to reply with IAC SB 3270-REGIME 
IS... IAC SE command. 


Since this negotiation is asymmetric, each time Telnet client/server 
decide to negotiate/renegotiate this option they have to perform 
complete negotiation process (DO... WILL... SB 3270-REGIME...). 


The following is an example of use of the option: 
1. Host A: IAC DO 3270-REGIME 
2. Host B: IAC WILL 3270-REGIME 
3. Host B: IAC DO 3270-REGIME 
4. Host A: IAC WILL 3270-REGIME 


Iy (At this point side which runs Telnet client can start 
subnegotiation.) 
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6. Host A: IAC SB 3270-REGIME ARE ’ibm3279-3 ibm3279-2 ibm3278-3’ 
IAC SE 


FR Host B: IAC SB 3270-REGIME IS ’ibm3279-2'’ IAC SE 
Implementation Suggestions 


If the side is able to support more that one terminal type, then 
terminal type names are listed in REGIME-LIST from most desirable to 
least desirable. Other side upon receive of the REGIME-LIST scans it 
from left to right and finds the first terminal type which it is able 
to support returns it in REGIME part of the 3270-REGIME IS 
subnegotiation. 


The side which wants to switch into NVT ASCII mode should send empty 
REGIME-LIST. Since empty string is a subset of empty string, the 
side which receives empty REGIME-LIST should reply with empty REGIME. 
At that point both sides are switched to NVT ASCII mode. 


It is possible to renegotiate 3270 Regime parameters (like terminal 
type). Certain precaution should be taken to insure that such 
renegotiation would not cause switch into NVT ASCII mode. Asa 
possible measure, the side which wants to renegotiate for another 
terminal should include both the current and the new terminal type 
names into REGIME-LIST. This way, if the other side is unable to 
change 3270 Regime terminal type, it will continue to use current 
terminal type. 


Since IAC character (255 decimal) is used as a delimiter (together 
with EOR) in inbound/outbound data stream, care must be taken to 
escape IAC characters which are part of data stream itself with 
another IAC character. 


To prevent ambiguity in interpreting inbound/outbound data stream 
during negotiation process the following rules should be observed: 


1. Telnet client should not accept any data from the user as soon 
as it enters 3270 Regime negotiation. 


2. Telnet client should not send any data to the Telnet server 
after it sends "3270-REGIME ARE....". 


3. Telnet server should try not to send any data to the telnet 
client while negotiation is in progress. 


4. Telnet server may reply with "3270-REGIME IS..." to the telnet 
client only after all outstanding data have been already sent 
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to the Telnet clie 
5. Telnet server can 
regime only after 
SE" to the telnet 
6. Telnet client can 
regime only after 
IAC SK". 
Ty 
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